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DETAILED ACTION 
Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the dirrci cnccs bciw eenthe subject matter sought to be patented and the prior art are 
such that the subject matter as a \vht)lc \v duIcI have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 

1 . Claim 2-6 are rejected under 35 U.S.C. 103(a) as being unpatentable over Kersley et al 
(US 2003/0172177) in view of Buechler et al (US 2002/0190356) as evidenced by English, ADA 
95: The Craft of Object-Oriented Programming, "Glossary". 

For claim 2, Kersley discloses A method for use in verification of a device comprising 
(see section 0007 "verification of a device under test"): 

providing a plurality of packet classes (see fig. 2; see various packet classes; section 
0005-7 "verify a device . . .packets can be built. . .selecting standard packet description 
headers andpacketpayloads...fi"om a packet database...."; section 0018, 0021-22, 0035; 
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section 0043 "tests... generate packets... combination of Ethernet, IPv4...."); 

a plurality of packet classes (see fig. 2; see various packet classes; section 0005-7 "verify 

a device . . .packets can be built. . .selecting standard packet description headers and 

packet payIoads...fi-om a packet data base...."; section 0018, 0021-22, 0035; section 

0043 "tests. . .generate packets. . .combination of Ethernet, Ipv4. . . ."); 

generating a packet (see fig. 2; see various packet classes; section 0005-7 "verify a device 

. . .packets can be built. . .selecting standard packet description headers and packet 

payloads...from a packet data base...."; section 0018, 0021-22, 0035; section 0043 

"tests. . .generate packets. . .combination of Ethernet, Ipv4. . . ."; section 0047), testing the 

device (see sections 0004-7 "generating packets to simulate. . .packet traffic patterns. . .to 

test and verify a device under test"; sections 0029-33) 

generated packet (see fig. 2; see various packet classes; section 0005-7 "verify a device 
. . .packets can be built. . .selecting standard packet description headers and packet 
payloads...from a packet data base...."; section 0018, 0021-22, 0035; section 0043 
"tests. . .generate packets. . .combination of Ethernet, Ipv4. . . ."). 

For claim 3, Kersley discloses A method for use in verification of a device (see section 

0007 "verification of a device under test") comprising: 

providing a plurality of packet classes (see fig. 2; see various packet classes; section 
0005-7 "verify a device . . .packets can be built. . .selecting standard packet description 
headers andpacketpayloads... from a packet database...."; section 0018, 0021-22, 0035; 
section 0043 "tests. . .generate packets. . .combination of Ethernet, IPv4. . . ."); 
generating a packet (see fig. 2; see various packet classes; section 0005-7 "verify a device 
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. . .packets can be built. . .selecting standard packet description headers and packet 
payloads... from a packet database...."; section 0018, 0021-22, 0035; section 0043 
"tests. . .generate packets. . .combination of Ethernet, Ipv4. . . ."; section 0047) and testing 
the device (see sections 0004-7 "generating packets to simulate. . .packet traffic 
patterns. . .to test and verify a device under test"; sections 0029-33); 
For claim 4, Kersley discloses A method for use in verification of a device (see section 
0007 "verification of a device under test") comprising: providing a plurality of packet 
classes (see fig. 2; see various packet classes; section 0005-7 "verify a device . . .packets 
can be built. . .selecting standard packet description headers and packet payloads. . .from a 
packet data base...."; section 0018, 0021-22, 0035; section 0043 "tests... generate 
packets. . .combination of Ethernet, IPv4. . . ."); 

generating a packet (see fig. 2; see various packet classes; section 0005-7 "verify a device 
. . .packets can be built. . .selecting standard packet description headers and packet 
payloads... from a packet data base...."; section 0018, 0021-22, 0035; section 0043 
"tests. . .generate packets. . .combination of Ethernet, Ipv4. . . ."; section 0047); testing the 
device (see sections 0004-7 "generating packets to simulate. . .packet traffic patterns. . .to 
test and verify a device under test"; sections 0029-33); 

For claim 5, Kersley discloses A method for use in verification of a device (see section 
0007 "verification of a device under test") comprising: 

(a) providing a plurality of packet classes (see fig. 2; see various packet classes; section 
0005-7 "verify a device . . .packets can be built. . .selecting standard packet description 
headers andpacket payloads... fi"om a packet database...."; section 0018, 0021-22, 0035; 
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section 0043 "tests... generate packets... combination of Ethernet, IPv4...."); 

(c) generating a packet (see fig. 2; see various packet classes; section 0005-7 "verify a 

device . . .packets can be built. . .selecting standard packet description headers and packet 

payloads...from a packet data base...."; section 0018, 0021-22, 0035; section 0043 

"tests. . .generate packets. . .combination of Ethernet, Ipv4. . . ."; section 0047); 

For claim 6, Kersley discloses repeating the steps of a and c (see section 0043, 0048, 

0061; multiple packets of generated using classes). 

Kersley does not explicitly discuss: 

For claim 2, providing a flag, which may be of a first or a second state, for each of the 
plurality of test types; if the flag of the test type of the accessed test is in the first state, 
changing the flag of the test type of the accessed test to the second state 
For claim 3, providing a flag, which may be of a first or a second state, for each of the 
plurality of test types; if the flag of the test type of the accessed test is in the first state, 
testing; if the flag of the test type of the accessed test is in the second state, not testing. 
For claim 4, providing a flag, which may be of a first or a second state, for each of the 
plurality of tests; if the flag of the test type of the accessed test is in the second state, not 
testing. 

For claim 5, providing an injection flag, which may be of a first or a second state, for 
each of the plurality of test t5^es; (e) if the injection flag of the packet class of the test is 
in the first state, testing and setting the injection flag of the test type of the accessed / 
completed test to the second state. 
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For claim 6, the steps of b, d, and e. 



Beuchler from the field of testing discloses the following: 

For claim 2, Buechler discloses providing a flag, which may be of a first or a second 
state, for each of the plurality of test types (see section 0078 "records 
flags. . .test. . .flagged. . .flag. . .test as being completed"; see Dl page 5; "Flag": A Boolean 
value which can be "set" to True or 'reset' to False"); if the flag of the test type of the 
accessed test is in the first state, changing the fiag of the test type of the accessed test to 
the second state (see section 0078 "records flags. . .test. . .flagged. . .flag. . .test as being 
completed"; see Dl page 5; "Flag": A Boolean value which can be "set" to True or 
'reset' to False"; if a test is accessed / completed it is flagged) 



For claim 3, Buechler discloses providing a flag, which may be of a first or a second 

state, for each of the plurality of test types (see section 0078 "records 

flags. . .test. . .flagged. . .flag. . .test as being completed"; see Dl page 5; "Flag": A Boolean 

value which can be "set" to True or 'reset' to False"); if the flag of the test type of the 

accessed test is in the first state, testing (see section 0078 "records 

flags. . .test. . .flagged. . .flag. . .test as being completed"; see Dl page 5; "Flag": A Boolean 

value which can be "set" to True or 'reset' to False"; if a test is not accessed / completed 

the flag is not set and test is performed) 

; if the flag of the test type of the accessed test is in the second state, not testing (see 
section 0078 "records flags. . .test. . .flagged. . .flag. . .test as being completed"; see Dl 
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page 5; "Flag": A Boolean value which can be "set" to True or 'reset' to False"; if a test 
is accessed / completed it is flagged and test is not performed) 



For claim 4, Buechler discloses providing a flag, which may be of a first or a second 

state, for each of the plurality of tests (see section 0078 "records 

flags. . .test. . .flagged. . .flag. . .test as being completed"; see Dl page 5; "Flag": A Boolean 
value which can be "set" to True or 'reset' to False"); if the flag of the test type of the 
accessed test is in the second state, not testing (see section 0078 "records 
flags. . .test. . .flagged. . .flag. . .test as being completed"; see Dl page 5; "Flag": A Boolean 
value which can be "set" to True or 'reset' to False"; if a test is accessed / completed it 
flagged and test is not performed) 



For claim 5, Buechler discloses providing an injection flag, which may be of a first or a 
second state, for each of the plurality of test types see section 0078 "records 
flags. . .test. . .flagged. . .flag. . .test as being completed"; see Dl page 5; "Flag": A Boolean 
value which can be "set" to True or 'reset' to False") 

(e) if the injection flag of the packet class of the test is in the first state, testing (see 
section 0078 "records flags... test... flagged... flag... test as being completed"; see Dl 
page 5; "Flag": A Boolean value which can be "set" to True or 'reset' to False"; if a test 
is not accessed / completed the flag is not set and test is performed) and setting the 
injection flag of the test type of the accessed / completed test to the second state (see 
section 0078 "records flags. . .test. . .flagged. . .flag. . .test as being completed"; see Dl 
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page 5; "Flag": A Boolean value which can be "set" to True or 'reset' to False"; if a test 
is accessed / completed flag is set). 



For claim 6, Buechler discloses repeating the steps of b, d, and e (see section 0078 

"records flags... test. ..flagged... flag... test as being completed"; see Dl page 5; "Flag": A 
Boolean value which can be "set" to True or 'reset' to False"; if a test is accessed / 
completed flag is set). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention to modify / combine the features of Kersley by using the above recited features, 
as taught by Beuchler, in order to provide a method a preventing duplication of testing, 
thus decreasing wasteful testing time and additional resources used by not performing 
tests that already have been performed (see Beuchler sections 0078). One could have 
implemented the teaching of Beuchler to the concept of test packets of Kersley, where 
flags are kept for the different packet types / combination. 



Response to Arguments 

Applicant's arguments filed 12/04/2009 have been fully considered but they are not 
persuasive. 

For claim 1 , the applicant argues that the combination of Kersey and Buechler does not 
teach the claimed language of claim 2-6. Specifically, the applicant argues that the claims 
require a single flag while Buechler disclose multiple flags. The examiner disagrees. It is 
pointed out to the applicant that the claims does not explicitly state "a single flag", but 
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merely "a flag". This claimed language does not exclude the possibility of having 
multiple flags for a packet class, but merely states that there is a flag for a packet class. 
The applicant argues that Buechler discloses two flags while the applicant uses one flag 
to perform the decision to test or not to test. The examiner takes the stance that either one 
of Buechler flags discloses this limitation. The flag that is set when a test is accessed ( 
and respectably not set, when it is not accessed) can be used to meet this limitation, since 
it discloses the method of having a flag for a test with states that indicate OK to test, 
NOT OK to test, and setting the state when a test is being conducted. Similarly, the 
second flag that is set when the test is completed can be used to teach the claimed 
language. Similarly, this flag is set when a test is completed (where further testing 
duplication is avoided) and conversely if the flag is not set the test is not completed and is 
ready for testing. Therefore this flag discloses the OK to test, NO test states and also 
setting the flag when a test is complete. It is implied that this flag is checked to see if the 
test is completed / is in progress so that test duplication of this particular test is avoided. 
This teaching corresponds to the claim limitations where the packet is tested if the flag is 
in a first state (corresponds to not set) and not tested if the flag is set (ie. it has been 
tested) Thus, the examiner takes the stance that either one of these two flag discloses the 
claimed language of claims 2-5. 

Further, the applicant argues that Kersley does not disclose a plurality of packet classes. 
The examiner disagrees. It is first pointed out no specific explanation of what specific 
characteristics a "packet class" entails therefore it is open to broadest reasonable 
interpretation. Further, the specification does not give a description either what specific 
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characteristics a "packet class" entails. The applicant merely discusses in the background 
of the invention different protocols and different combination of legal packets. Similarly, 
Kersley discloses multiple types and variants of packets, having for example different 
protocols (see fig. 2 section 0043, Ethemet, TCP, IP etc packet classes) and fiirther for 
each protocol different format and combination of parameters. The examiner takes the 
stance that these different types of packet types (protocols, legal packet combinations etc) 
are equivalent with "packet classes". Further the discussion in the background of 
invention where different combination and protocol and packet classes are discussed are 
consistent with the teaching of Kersley. The applicant is invited to show where the 
specification / claims explain what a "packet class" entails and how it is differentiated 
from the teachings of Kersley. 

Lastly, the applicant argues that the combination of Kersley and Buechler would not have 
been made by a person of ordinary skill in the art. The examiner explained that the 
implementation of flag, (ie. merely a one bit variable), a simple and well known method 
of keeping track of a state, could be implemented into the digital system of Kersley and 
fiirther that it would be obvious to a person of ordinary skill in the art to do so, in order to 
prevent testing packet types / combination multiple times. Therefore, duplication of 
testing is avoided (as suggested by Buechler in section 0078) and potential waste 
resources ( processing time, bandwidth in the network, testing duration etc). 
Implementation of a flag in a digital / computer system for a keeping a state is 
fimdamental and well known to a person of ordinary skill in the art. Implementing the 
flags to prevent testing duplication would not change the basic nature of having / 
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producing different packet classes, but would merely avoid duplication of testing of 
similar or same packet types / variants. 

Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS fi-om the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

2. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to ICENAN CEHIC whose telephone number is (571)270-3120. 
The examiner can normally be reached on Monday through Friday 8:00-5:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, KWANG BIN YAO can be reached on (571) 272-3182. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained trom the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Kenan Cehic/ 
Examiner, Art Unit 2416 



/KWANG B. YAO/ 

Supervisory Patent Examiner, Art Unit 2473 



